Skip to content

GDP: Fix bug transforming Blocks in gdp.mbigm transformation#3811

Merged
emma58 merged 11 commits intoPyomo:mainfrom
bammari:mbigm-resolve-names
Feb 10, 2026
Merged

GDP: Fix bug transforming Blocks in gdp.mbigm transformation#3811
emma58 merged 11 commits intoPyomo:mainfrom
bammari:mbigm-resolve-names

Conversation

@bammari
Copy link
Contributor

@bammari bammari commented Jan 9, 2026

Fixes # .

The multiple big-M transformation fails to transform blocks.

Summary/Motivation:

In many cases, we may want to apply the multiple big-M transformation on blocks rather than an entire model.

For example, prior to this PR the following model would result in a failed transformation:

import pyomo.environ as pyo
from pyomo.gdp import Disjunction, Disjunct

m = pyo.ConcreteModel()
m.b = pyo.Block()
m.b.x = pyo.Var(bounds=(0, 5))
m.b.y = pyo.Var()
m.b.dis1 = Disjunct()
m.b.dis2 = Disjunct()

m.b.dis1.linear = pyo.Constraint(expr = m.b.x*0.5 + 3 == m.b.y)
m.b.dis2.linear = pyo.Constraint(expr = m.b.x*0.2 + 1 == m.b.y)
m.b.d = Disjunction(expr = [m.b.dis1, m.b.dis2])

pyo.TransformationFactory('gdp.mbigm').apply_to(m.b, threads=1)

Changes proposed in this PR:

  • Add argument relative_to=instance on constraint.getname() and other_disjunct.getname() when setting up jobs for calculating M parameters.
  • Add a test that applies the multiple big-M transformation on a block to ensure no failures occur.

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

  1. I agree my contributions are submitted under the BSD license.
  2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

@emma58 emma58 changed the title Mbigm resolve names GDP: Fix bug transforming Blocks in gdp.mbigm transformation Jan 9, 2026
Copy link
Contributor

@emma58 emma58 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much for fixing the bug, @bammari! Do you have time to add a few assertions about the transformed model to your test?

@codecov
Copy link

codecov bot commented Jan 9, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.44%. Comparing base (e0fcc81) to head (94a14d2).
⚠️ Report is 250 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3811      +/-   ##
==========================================
- Coverage   89.45%   89.44%   -0.01%     
==========================================
  Files         905      905              
  Lines      105467   105467              
==========================================
- Hits        94341    94338       -3     
- Misses      11126    11129       +3     
Flag Coverage Δ
builders 29.15% <ø> (+<0.01%) ⬆️
default 86.07% <ø> (?)
expensive 35.77% <ø> (?)
linux 86.77% <ø> (-2.45%) ⬇️
linux_other 86.77% <ø> (ø)
osx 82.92% <ø> (ø)
win 84.99% <ø> (-0.01%) ⬇️
win_other 84.99% <ø> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Comment on lines +1210 to +1212
m.b.dis1.linear = Constraint(expr=m.b.x * 0.5 + 3 == m.b.y)
m.b.dis2.linear = Constraint(expr=m.b.x * 0.2 + 1 == m.b.y)
m.b.d = Disjunction(expr=[m.b.dis1, m.b.dis2])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick question: this tests the case where all the variables are defined by the subtree being transformed. What happens if one of the Vars is defined outside the subtree (e.g., on m instead of under m.b)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jsiirola In this example, if we defined variable x as m.x instead of m.b.x, the transformed expression would be:

0.5 * m.x + 3 - m.b.y <= 3.5 * m.b.dis2.binary_indicator_var instead of

0.5 * m.b.x + 3 - m.b.y <= 3.5 * m.b.dis2.binary_indicator_var

Do you see any potential issues with this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope - that should be fine. I don't think it will be a huge issue, as the change this PR is making doesn't actually affect Vars (I wasn't thinking clearly last night -- you are only getting relative names for active components [Constraints & Disjuncts] - and not Vars).

BUT, this does raise the question: what do we expect the following to do??

m.d1 = Disjunct()
m.b = Block()
m.b.d2 = Disjunct()
m.b.disj = Disjunction(expr=[m.d1, m.b.d2])
TransformationFactory('gdp.mbigm').apply_to(m.b, threads=2)

Thoughts? @emma58?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Spot checking... this update to mbigm leads to an exception. bigm will transform the model (including deactivating m.d1)

Copy link
Contributor

@emma58 emma58 Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(@emma58 crawls under a table...)

(From under the table,) we expect the model above to put the transformed constraints on m.b, and to deactivate m.d1 and m.b.d2. Scoping should be determined by the Disjunction and not care about where the Disjuncts are living at all. So basically, the bigm behavior is the desired behavior. I can look at this...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So actually, the model above transforms without error on this branch (both with m and m.b as the Block being transformed). Even this transforms correctly, as a fun fact:

from pyomo.environ import *
from pyomo.gdp import *

m = ConcreteModel()

m.x = Var(bounds=(0, 10))
m.d1 = Disjunct()
m.b = Block()
m.b.y = Var(bounds=(3, 15))
m.b2 = Block()
m.b2.d2 = Disjunct()
m.b2.d2.c1 = Constraint(expr=m.x <= 7)
m.b2.d2.c2 = Constraint(expr=m.b.y <= 7)

m.b.disj = Disjunction(expr=[m.d1, m.b2.d2])
TransformationFactory('gdp.mbigm').apply_to(m.b, threads=2)

We're somehow getting away with the relative names, though I admit I'm not fully following how at the moment.

@blnicho blnicho moved this from Todo to Review In Progress in Pyomo 6.10 Jan 23, 2026
@mrmundt mrmundt requested a review from emma58 January 27, 2026 19:41
@github-project-automation github-project-automation bot moved this from Review In Progress to Reviewer Approved in Pyomo 6.10 Feb 10, 2026
@emma58 emma58 requested a review from jsiirola February 10, 2026 20:25
Copy link
Member

@jsiirola jsiirola left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we've convinced ourselves that this is OK.

@emma58 emma58 merged commit 4e91199 into Pyomo:main Feb 10, 2026
35 checks passed
@github-project-automation github-project-automation bot moved this from Reviewer Approved to Done in Pyomo 6.10 Feb 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

No open projects
Status: Done

Development

Successfully merging this pull request may close these issues.

5 participants